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ABSTRACT 


Automation of several payment processes from start to end is a challenging 
task, particularly when multiple payments from online and offline billers are 
involved. In this paper, we introduced a new aggregator system to combine all 
billing system types, in which it is possible to pay invoices electronically. The 
proposed aggregator system was designed to be employed in a cloud-based 
billers hub (CBBH) developed by the central banks. Furthermore, many 
applications can be realized such as; deposit e-money, withdrawal e-money, 
and other applications. A Gateway translator is used to apply authentication 
rules, security, and privacy. The proposed system was employed in the 


Jordanian payment gateway and successfully fulfills its purpose. 
Cloud computing 


Electronic bill presentment and 
payment 


Internet billing system This is an open access article under the CC BY-SA license. 


Corresponding Author: 


Mahdi A. Nisirat 

Department of Communications Engineering Technology 
Faculty of Engineering Technology 

Al-Balga Applied University, Jordan 

Email: mamnisirat@bau.edu.jo, mamnisirat@gmail.com 


1. INTRODUCTION 

E-payment applications are among the most promising innovations that shift consumers from using 
traditional bill payment to electronic alternatives [1, 2]. Electronic bill presentment and payment (EBPP) is the 
process by which companies present invoices through the internet and make payments to one another. Most of 
the Internet billing system is designed utilizing cloud computing technology. Several countries build their own 
cloud payment gateways to unify payment issues [3-8]. The two primary E-payment models are the biller- 
direct model and the aggregation model. In the aggregation model, the aggregator combines data from multiple 
billers and consolidates the information at a single destination. Several Internet-based billing systems models 
were suggested in the literature. As part of this proposal, several Internet-based billing systems models were 
suggested in the literature [6-16]. 

This paper represents a proposal to any Central Bank intend to establish a cloud-based billers hub 
(CBBH). It aims to define the technical requirements and the functional boundaries needed. It also depicts a 
high-level view of the envisioned architecture and presents the expected timeline and implementation 
approach. This paper serves as a reference for future analysis, design, and implementation activities. 

The audiences targeted by this paper include the following: 

— The sections on functional view, implementation approach, and paper timeline would be their primary focus. 
— System Analysts from all involved parties. Their primary focus would be the sections on functional view 
and architectural overview. 
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— Architects from all parties. Their primary focus would be the section on the proposed solution. 
— Technical team leads from all parties. Their primary focus would be the sections on the proposed solution, 
implementation approach, and timeline. 

While the above points indicate which sections are most important for which audience, all other 
sections are somehow relevant to all. In such a case, it is advisable that the paper be reviewed in its entirety. 
Technical audiences that are not listed above (e.g. developers) are likely to base their work on the more 
elaborate papers that will be based on this proposal. The following list represents the papers and sources of 
information upon which the content of this paper was based: 

— Relevant documentation from central Bank in particular: 
— Through the analysis of the national payment gateway platform, and how it integrates with billers. 

The scope of this paper is limited to the proposed biller hub solution. The proposed work will be 
integrated with various types of billers, and with national payment gateway (as the primary bank/PSP hub e- 
payments). The proposed cloud-based billers hub (CBBH) will provide all the facilities needed to enable both, 
direct and indirect billers on national payment gateway. 

As illustrated in Figure 1, the national payment gateway facilitates payments between customers and 
billers. The proposed gateway provides a platform that integrates banks and other Payment Service Providers 
(PSP’s) with the various types of billers [17-20]. In other words, it encompasses a national Bank/PSP hub as well 
as a biller hub. 

The purpose of this paper is to implement a self-contained, reliable, and scalable biller hub that would 
decouple the billers from the national payment gateway platform. A direct consequence is that it would abstract 
all aspects concerning the integration with billers, as well as the details of how billing data are obtained from, 
and how payment notifications are delivered to billers. The proposed cloud-based billers hub (CBBH) will 
provide all the facilities needed to enable both, direct and indirect billers on national payment gateway. 
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Figure 1. National payment gateway-the need for a biller hub 


2. PROPOSED METHOD 

This section introduces the main concepts and provides detailed necessary information to clarify the 
basic functions for the cloud-based billers hub (CBBH). Also, it illustrates how billers classified to small, mid 
and big, regarding to volume of daily transactions, from biller to the national payment gatway and vise versa. 
The provided subsections atarting from the functional view sub-section down to the costumer support 
sub-section are meant to clarifty the important role of each of them as part of the proposed scheme. 


2.1. Functional view 

The CBBH is meant to provide a cloud-based service that enables billers to become integrated with 
national payment gateway in a standard and loosely-coupled manner, without direct technical involvement of 
national payment gateway. In other words, CBBH is meant to decouple the integration of billers from national 
payment gateway as shown Figure 2. depicts a high-level functional view of national payment gateway with 
CBBH. It also provides a Biller Portal, through which Small and Medium Billers (such as schools and 
universities who are typically technically-unready to integrate with national payment gateway) can manually 
upload billing data, view reports, and import payment data. 


2.1.1. Types of billers 

As will be explained throughout this paper, the proposed CBBH takes into consideration the various 
sizes of billers (i.e. small and medium).Their different levels of technical integration readiness, either online or 
offline, are also clarified. Finally, the business nature of billing data where also highlited for the completeness of 
the description. 
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a. Online billers 

Online billers (also referred to as integrated billers) are mostly enterprise-level billers. Such a kind of 
billers are considered as technically capable of integrating with national payment gateway using either the pull 
or push integration model. They are enabled on national payment gateway via direct integration with CBBH 
integrated services. 
b. Offline billers 

Offline billers which may be concerned in all small or medium billers only. This type of billers have 
no IT infrastructure so it can not be integrated technically with the national payment gateway through the 
CBBH biller portal. Thus, it needs to be enabled and fully defined to clarify its operational criteria. 
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Figure 2. National payment gateway with CBBH - functional view 


2.2. E-Commerce sites 

In later stages, CBBH is planned to enable e-commerce sites to integrate with registered CBBH in 
a simple unified HTTP redirection model. This will enable customers to obtain an active billing number 
at national payment gateway. Once the payment is made, CBBH passes the payment notification back to 
the e-commerce biller, which in turn, delivers the services/goods to the customer. This will allow customers to 
select their preferred PSP from within the e-commerce site, which would result in the customer being 
dynamically redirected to the PSP payment facility. Once the payment is made, CBBH passes the payment 
notification back to the e-commerce biller, which in turn, delivers the services/goods to the customer. CBBH 
provides billers with the ability to integrate directly with its core platform (through Integrated Services), as 
well as a Biller portal and an Operations/Admin portal. The following sections describe the main functional 
use cases enabled through CBBH. 


2.3. Integrated services 

The two main use cases provided by the core component of CBBH (integrated services) are called as 
the inquiring of billing data and the delivery of payment notifications. Further details of these cases are deeply 
pronounced in the operational perspective section. Enabled billers to export payment notifications data will be 
in different formats (e.g. XML, CVS). Such notifications are to view and export operation reports, payment 
notifications, bills statuses, and etc. 


2.4. Biller portal 

It is known that one of the applications of the integrated services of CBBH is to enable automated 
retrieval of billing data from online billers and the delivery of payment notifications to online billers. In addition 
to that, the Biller portal enables offline billers to manually upload billing data, and download/receive payment 
notifications. Table | defines the main use cases of the biller portal. 


2.5. Ops/admin portal 

Away from the biller portal, the Ops/Admin portal provides operations and customer support 
personnel with monitoring and control facilities. Moreover, it will facilitate the generation/export of usage 
reports, and the handling of customer complaints and inquiries. It also provides administrators with facilities 
for administering user account, role-based permissions, and system parameter settings. 


2.6. Supplementary features 

Billar portal use cases are an important course of applications to be mentioned, described and 
emphasized. The included cases of such an application are clarified briefly in Table 1. They include the upload 
billing data, download payment notifications export report notifications, and finally, the view activity logs. On 
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the other hand, the CBBH may constitute many different features as basic to the system. Following this context, 
the main supplementary features that may be assumed as fundamental and necessary by the CBBH are: 

— Multi-lingual support 

— Context-sensitive help 

— Secure communication 

— Logging and audit trail 

— Notification delivery re-attempts 

— Exception detection, handling, and reporting 

— Responsive web interface, to support different sizes of screens 

— High availability and fail over/disaster recovery site setup 


Table 1. Biller portal use cases 


Use Cases Description 
Upload Billing Data Enables offline billers to upload batches of billing data. These data are made available for 
customers to view and pay for through supported electronic payment means (Banks and PSP’s). 
Download Payment Notifications Enables billers to export payment notifications data in different formats (e.g. XML, CVS). 
View/Export Operation Reports Enables billers to view and export operation reports, concerning billing data, payment 
notifications, bills statuses, etc. 
View Activity Logs Keeps track of all activities performed on the portal. 


2.7. Initial set of billers 

CBBH will eventually support all types of billers, including online billers (in both “push” and “pull” 
mode) and offline billers. This phase of the paper will aim to launch a solution with pilot billers of each type. 
Through its biller portal, CBBH will allow for rapid onboarding of offline billers. 


2.8. Architectural view 

The cloud-based biller hub architecture will be discussed by two perspectives, the logical perspective 
and operational perspective. This will illustrate the major two modes of operation the pull mode and the push 
mode. The main features will be illustrated in the two following paragraphs. 


2.8.1. Logical perspective 

The logical perspective describes the integration operation between billers and the current payment 
gateway. Two modes, mainly the push mode and the pull mode, are used to describe such perspectives. Both 
of the modes are described in the next subsections. 
a. Integration with biller 

Figure 3 represents the current situation from an integration perspective. It shows a logical depiction 
of the direct integration between the national payment gateway and a given biller (Biller X). Online billers 
would be integrated with the national payment gateway either in a Push mode or in Pull mode. In push mode, 
the biller would be expected to upload billing data to national payment gateway using different means (such as 
FTP, or a web service exposed by national payment gateway). On the other hand, in pull mode, the national 
payment gateway would be expected to retrieve billing data on demand, by calling a web service exposed by 
the biller (billing service). 
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Figure 3. National payment gateway Integration with billers 
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b. Integration with national payment gateway 

With CBBH, national payment gateway will continue to facilitate payments through various channels 
to the growing number of billers and small billers without causing any major disruption to the existing 
integration approach. CBBH will act as a biller aggregator, and will hence take care the technical onboarding 
of new billers (through a proposed set of management commands), as well as retrieving billing data and 
dispatching payment notifications (through the billing and payment notifications services) [21-25]. CBBH also 
enables small billers to upload billing data and export payment notification data through the Biller Portal. This 
is clarified pictorially as shown in Figure 4. 
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Figure 4. Integration with Billers through CBBH 


2.8.2. Operational perspective 

CBBH is concerned with a number of processes. As an example, the technical on-boarding of billers, 
inquiry/retrieval of billing data from billers, and the delivery of payment notification data to billers, are 
considered as part of the most important processes. None the less, generating and exporting both transactional 
and statistical reports is also considered under the main duties of CBBH. The following sections describe the 
main focal processes. 

a. Inquiring of billing data 

CBBH facilitates the retrieval of billing data so that customers can pay their due payments through 
the various payment channels provided by national payment gateway. Figure 5 illustrates the billing data 
inquiry process. 

— The operations/sales personnel complete the registration and onboarding of the biller through the CBBH’s 
operations portal. 

— The new biller is activated for national payment gateway. Consequently, the biller becomes visible (and 
its billing data becomes accessible) although the various payment channels supported by national payment 
gateway . 

— When attempting to pay, the customer inquiries about the bills and due payments by entering relevant 
data retrieval keys (e.g. phone or meter number and billing period) . 

— National payment gateway sends a bill inquiry request to CBBH. The request would embed the biller Id 
along with the data retrieval keys. 

— Based on the biller’s integration mode (pull or push), CBBH would either dispatch the request to the 
concerned biller or return the billing data directly from within CBBH’s secure data store. 

— Incase the biller is integrated with CBBH according to the pull mode, CBBH would submit the billing 
data inquiry to the billing service exposed by the concerned biller . 

— CBBH returns corresponding biller data to national payment gateway, which in turn delivers it to the 
customer through the payment channel. 

b. Delivery of payment notifications 

Once billing data is retrieved through CBBH, and the due amount is paid through one of the PSP’s 
supported by national payment gateway, the biller is eventually notified. Consequently, the biller would reflect 
the payment data onto their financial records and would deliver the service or commodity that has been paid 
for. Figure 6 illustrates the payment notification delivery process. Notice that small billers are typically not 
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ready for direct technical integration, and therefore access payment notification data through CBBH’s Biller 
Portal or through other provisioned means such as a merchant’s mobile payment app. CBBH can also be 
optionally set to send payment notifications through conventional electronic means, such as email and SMS. 








Bayment Data Delivery 


Figure 6. Payment notification data delivery — flow 


2.8.3. Physical perspective 

Physical perspective in this context means two major critical issues. These two issues are the 
deployment and high availability with disaster recovery. The later issue is used in case a service framework is 
designed to meet the demands of enterprises to bring resiliency to business models. Such resiliency act would 
deliver uninterrupted services, or a non-stop service to the CBBH system. 
a. Deployment 

We are willing to accommodate any regulations that may favor or restrict the deployment of CBBH 
in a given environment, as long as the scalability and reliability requirements are met. Nevertheless, the hosting 
of CBBH during the early stages of operations will be at a local cloud-based data center that provides 
on-demand infrastructure as a service (IaaS) such as VTEL. It is worthwhile considering moving the virtual 
setup to data centers as the number of billers increase. 
b. High availability and disaster recovery 

Technically speaking, CBBH can be deployed in any reliable and scalable environment. To ensure 
business continuity, the deployment setup must also account for disaster recovery (DR), which could be 
cloud-based. Data should be replicated in near real-time so that failover can happen within a matter of minutes. 
DR will be active/standby during implementation Phase I. It will be transformed to Active/Active in Phase II. 
As depicted in Figure 7, CBBH will be connected with national payment gateway over redundant connections 
(main and backup) through two different providers. To increase the reliability and scalability of the 
connections, they shall support multi-protocol label switching (MPLS). 
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Figure 7. Redundant backup connections 


2.8.4. Other quality attributes 

Many attributes are worth of clarifying and explaining. The most important to illustrate are related to 
security, performance and audit trail. The audit trail must be supported by sufficient documentation to follow 
a transaction from beginning to end. The user should maintain an adequate audit trail of all transactions. 
a. Security 

Secure electronic transaction was an early communications protocol used by e-commerce websites to 
secure electronic payments. Secure electronic transaction was used to facilitate the secure transmission of 
consumer card information via electronic portals on the Internet. This will prevent hackers, and electronic 
thieves from accessing consumer information. The Cloud base biller hub communication with national 
payment gateway and billers will be secured to ensure the privacy of confidential data, authentication, non- 
repudiation and, data integrity. 
1) CBBH and national payment gateway 

Toughened requirements to banks on protection of means of clients against cybercriminals, follows 
from new provision of the Central Bank. The Central Bank introduces new requirements to cyber security of 
brokers. Cloud biller base hub solution will comply with the security requirements imposed by the Central 
Bank for Cloud Service Providers. 
2) CBBH and Billers 

The following security methods will be applied to secure the communication between CBBH and billers: 
— Securing connections using TLS. This will involve exchanging certificates with billers as part of the 

official biller onboarding process. 

— Applying additional end-to-end message-level encryption for sensitive data as needed. 
— Applying non-repudiation mechanisms using message digest algorithms such as SHA 256. 
Dedicated links between all sites are recommended to achieve max security. However, it has an impact on 
operations cost to maintain high availability. Site-to-site VPN is an alternative way for connectivity. 
b. Performance 

In the case of electronic payment (Transactions), more complex performance monitoring is needed., 
the continuous monitoring and the scalable nature of the virtualized cloud-based environment will be deployed 
to offer timely, adaptability and consistent performance. Further evaluation and refinement will be performed 
and will mostly focus on resolving issues and optimizing biller on boarding and operations. Eventually, after 
conducting operations and administration training, CBBH will go live at full scale, supported by close 
monitoring and customer support 
c. Logging and audit trail 

CBBH will log and keep track of all actions performed on or through it. This includes all transactions 
data (and in particular, financial records pertaining to payment notifications), as well as administrative action 
performed through the sales/admin portal, and data import and export actions performed by small billers 
through the biller portal. Logging and archiving will be implemented in accordance with the regulations and 
durations specified by CBJ in the referenced papers. 


2.9. Maintenance & Support 
Full responsibility for all required maintenance & support activities, including: 
— Continuous monitoring of overall system performance to identify possible bottlenecks and intervene when 
needed. 
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— Regular reviews of system logs to identify possible issues and intervene as needed. 
— Analysis of issues and bugs that may be observed or reported by operation personnel, and resolving them 
in a timely manner, based on their level of severity as in Table 2. 


Table 2. Maintenance and support issues 


Severity Level Description SLA 

Critical Issues that suspend business operation, or endangers data integrity. For example: Intervention within 2 hours 
A system-wide failure (Software, Hardware or Network) Resolution within 24 hours 

High Issues that highly impede business operations. For example: Network or Hardware Intervention within 24 hours 
failure affecting multiple service/participants Resolution within 48 hours 

Intermediate Issues that intermittently impede business operations. For example: Network or Intervention within 48 hours 
Hardware failure affecting single service/participant Resolution within 3 days 

Low Issues that have no impact on business continuity and data integrity. For example: Intervention within 1 week 


Issues with Bills Reports, Customer Profile, System Logs and Transaction logs Resolution within 3 weeks 
Reports 


3. IMPLEMENTATION APPROACH 

The implementation of CBBH will follow an iterative incremental approach that will involve multiple 
parallel work streams. Upon paper start, requirements will be revisited, further analyzed, and detailed/refined 
as needed. After the sign-off of the requirements, detailed blueprints will be produced, followed by the kick 
off of main work streams; CBBH Core, Ops/Admin Portal, and Biller Portal. During this time, We will work 
with pilot billers of different types (1.e. “pull” and “push” integrated billers, as well as small billers). After 
thorough testing, CBBH will be soft-launched with the pilot billers only. 


4. WORK BREAKDOWN STRUCTURE 

Table 3 illustrates the work breakdown structure that provides a high-level view of the Work 
breakdown structure. They were subdivided into three main levels level one, two and three. Each one of them 
were described by their relevance and importance according to the context of operation. The main paramters 
of level 1 are given as inspection, elaboration, construction, and transition, respectively. The other levels are 
as described in Table 3. 


Table 3. Work Breakdown Structure (WBS) 
High-Level CBBH Implementation WBH 
Level 1 Level 2 Level 3 
Inspection Requirements Analysis 
Agreement with Pilot Billers 
Specification of Software requirements 


Elaboration Baseline Architecture Blueprints Specification of Software Architecture 
Integration specifications. 
CBBH Core CBBH Platform 
Integration with e-Fawateerkum 
- Billing data inquiry 


- Payment notifications 
Integration with Pilot Billers 
- Pull 
- Push 
Managements Commands 
Refined Architecture Blueprints 
Construction CBBH Core Use Cases 


Ops/Admin Portal Biller Management 
Administration 
Settlements 
Reports 

Biller Portal Basic Biller support 


Support for Micro Billers 
Transition UAT 
Training 
Rollout Planning 
Pilot/ Soft launch 
Operations Optimization 


Full Scale Production (Live) 
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5. CONCLUSION 

In this paper, we developed an aggregator system that can be integrated into an Internet billing system 
developed by central banks. The proposed method defined the technical requirements and the functional 
boundaries needed. It also depicted a high-level view of the envisioned architecture and presented the expected 
timeline and implementation approach. The proposed method was successfully implemented in the cloud-based 
Billers Hub developed by the central bank in Jordan. 


REFERENCES 

[1] U. Arnold, J. Oberlander, and B. Schwarzbach, "Logical-development of cloud computing platforms and tools for 
logistics hubs and communities," in Federated Conference on Computer Science and Information Systems, FedCSIS 
2012. pp. 1083-1090, 2012. 

[2] R. Buyya, J. Broberg, and AM. Goscinski, "Cloud computing: Principles and paradigms," vol. 87. John Wiley & 
Sons, 2010. 

[3] M. Milroy and F. Li, "Internet billing: the experience from four UK utility companies," International journal of 
information management, vol. 21, no. 2, pp. 101-121, 2001. 

[4] "Business-to-Business EIPP: Presentment Models, Part 1, " Council for Electronic Billing and Payment, 2001. 

[5] S. Sumanjeet, "Emergence of payment systems in the age of electronic commerce: The state of art," Global Journal 
of International Business Research, vol. 2, no. 2, 2009. 

[6] P.S. Barreto, G. Amvame-Nze, C.V. Silva, et al., "A study of billing schemes in an experimental next generation 
network," in International Conference on Networking, Springer, Berlin, Heidelberg, pp. 66-74, 2005. 

[7] G. Antoniou, B. Lynn, N. Shivaramakrishnan, et al., "A privacy preserving e-payment scheme," in Intelligent 
Distributed Computing IIT, Springer, Berlin, Heidelberg, pp. 197-202, 2009. 

[8] O. W. Purbo, "Internet-offline solution: detail description and benchmarking," TELKOMNIKA Telecommunication 
Computing Electronics and Control, vol. 18, no. 4, pp. 1809-1818, 2020. 

[9] E.S. Pramukantoro, M. Luckies, and F.A. Bakhtiar, "Bridging IoT infrastructure and cloud application using cellular- 
based internet gateway device," TELKOMNIKA Telecommunication Computing Electronics and Control, vol. 17, 
no. 3, pp. 1439-1446, 2019. 

[10] A.K.M. Ibrahim, R.A. Rashid, A.H.F.A. Hamid, et al., "Lightweight IoT middleware for rapid 
application development," TELKOMNIKA Telecommunication Computing Electronics and Control, vol. 17, no. 3, 
pp. 1385-1392, 2019. 

[11] R.A.P. Rajan, "A review on serverless architectures-function as a service (FaaS) in cloud computing," 
TELKOMNIKA Telecommunication Computing Electronics and Control, vol. 18, no. 1, pp. 530-537, 2020. 

[12] P.P. Vishwakarma, A.K. Tripathy, and S. Vemuru, "An empiric path towards fraud detection and protection for NFC- 
enabled mobile payment system," TELKOMNIKA Telecommunication Computing Electronics and Control, vol. 17, 
no. 5, pp. 2313-2320, 2019. 

[13] A. Al Farawn, H.D. Rjeib, N.S. Ali, et al., "Secured e-payment system based on automated authentication data and 
iterated salted hash algorithm," Int J Pow Elec & Dri Syst, no. 8694, 2020. 

[14] E. Van, L. Toader, S. Talluri, et al., "Serverless is more: From paas to present cloud computing," IEEE Internet 
Computing, vol. 22, no. 5, pp. 8-17, 2018. 

[15] T. Lynn, P. Rosati, A. Lejeune, et al., "A preliminary review of enterprise serverless cloud computing (function-as- 
a-service) platforms," in JEEE International Conference on Cloud Computing Technology and Science, CloudCom 
2017. pp. 162-169, 2017. 

[16] G. McGrath and P. R. Brenner, "Serverless computing: Design, implementation, and performance," in JEEE 37th 
International Conference on Distributed Computing Systems Workshops, ICDCSW 2017. pp. 405-410, 2017. 

[17] R. Rajeshkumar, R. Mohanraj, and M. Varatharaj, "Automatic Barcode Based Bill Calculation by Using Smart 
Trolley," International Journal of Engineering Science and Computing, vol. 6, no. 3, 2016. 

[18] J. Iyer, H. Dhabu and S.K. Mohanty, "Smart Trolley System for Automated Billing using RFID and ZIGBEE," 
International Journal of Emerging Technology and Advanced Engineering, vol. 5, no. 10, 2015. 

[19] P.Chandrasekar and T. Sangeetha, "Smart Shopping Cart with Automatic Billing System through RFID and ZigBee," 
in proceedings of IEEE International Conference on Information, Communication and Embedded System, ICICES 
2014. pp. 1-4, 2014. 

[20] S. Rohith and C. Madhusudan, "Easy Billing System at Shopping Mall Using Hitech Trolly," International Journal 
& Magazine of Engineering, Technology, Management and Research, vol. 2, no. 7, 2015. 

[21] H. T. Ranjitha and M. Chethana, "Advanced billing system for government departments," International Journal of 
Advance Research, Ideas and Innovations in Technology, Vol. 5, no. 2, 2019. 

[22] Z. Benazir and P. Prabha, "Electricity Bill Management System," International Journal of Applied Engineering 
Research, Vol. 13, no. 5, 2018. 

[23] H. Sherrie, R. Shreya, J. Suganya, et al., "Development of an android application for electricity bill payment," 
International Journal of Advance Research in Science and Engineering, IJARSE 2015, vol. 4, Issue 01, 2015. 

[24] J. Wang, "Design and Implementation of Property Tax Grid Management System," JEEE Workshop on Advanced 
Research and Technology in Industry Applications, 2014 WARTIA, 2014. 

[25] C. Dawne, "Electronic Billing: Understanding the Road to Adoption, DST Output," White Paper. 2002. 


A proposed cloud-based billers hub using secured e-payments system (Belal Ayyoub) 


348 O ISSN: 1693-6930 


BIOGRAPHIES OF AUTHORS 


Belal Ayyoub received his B.Sc. and M.Sc. (1999), from the Faculty of Engineering 
Technology, Alex. Egypt AAST&MT, Ph.D. (2009) in Computer Information System 
(Complex computer networks) from the Arab Academy for Banking and Financial Sciences 
Jordan. Currently he is an associate professor at the Department Of computer engineering 
BAU University, Amman Jordan. His research interests include cloud computing, computer 
digital image processing, Complex computer networks design and optimizations. 

Email: belal_ ayyoub@bau.edu.jo. 


Bilal Zahran received the B.Sc degree in Electrical & Electronic Eng. from Middle East 
Technical University, Turkey, in 1996, the M.Sc degree in Communications Eng. from 
University of Jordan, Jordan, in 1999, and the PhD degree in Computer Information System 
(CIS) from Arab Academy for Banking and Financial Sciences, Jordan, in 2009. He is currently 
working as an Associate Professor at the department of Computer Engineering, Faculty of 
Engineering Technology, Al-Balqa Applied University, Jordan. His research interests include 
artificial intelligence applications, optimization and digital signal processing fields. 

Email: zahranb@bau.edu.jo, zahranb@yahoo.com 


Mahdi Nisirat is currently a faculty member and an associate professor at the Department of 
Communications Engineering Technology, the Faculty of Engineering Technology, Al-Balqa 
Applied University, Jordan. He holds a Ph.D. degree from the Universiti Kebangsaan 
Malaysia, Malaysia; an MSc degree in Electrical Engineering from the University of Texas 
at Arlington, USA; and a BSc degree in Mathematics-Physics (double major) from King 
Abdul Aziz University, Saudi Arabia. His current research interests include cellular path loss 
prediction and optimization, microwave propagation modeling, MIMO systems, and 
techniques. Dr. Nisirat is currently the IEEE COMSOC head of the Department of 
Communications Engineering Technology. 

Email: mamnisirat@bau.edu.jo. 


Faroug M. S. Al-Taweel, ia an Associate Professor of Communication Engineering. He 
holds a PhD in Engineering Communication and information technology from Moscow 
Technical University of Communication and information. 

Email: dr_farouq@bau.edu.jo. 


Mohammad AI Khawaldah is a faculty member at Al-Balqa Applied University from 2010. 
He received his BSc in Electronic Engineering from University of Technology, Baghdad 
(1999), MSc in Mechatronics Engineering from Al-Balqa Applied University/Jordan (2005) 
and PhD degree (Exploration and Map building by Cooperating Mobile Robots) from 
University of Hertfordshire, UK (2010). Currently, he is an associate professor in 
Mechatronics Engineering Department at Al-Balqa Applied University. His research interests 
include: Mobile robot exploration and navigation, multi-robot cooperation and Search and 
Path planning algorithms. He worked as a visiting researcher in Wurzburg University and in 
Jacobs university in Germany as he got funds from the German Research Foundation (DFG). 
Email: m.alkhawaldah@bau.edu.jo. 





TELKOMNIKA Telecommun Comput El Control, Vol. 19, No. 1, February 2021: 339 - 348 


